ATTACHMENT A 


Summary of Work Performed Under Task #2 of NAS5-32374 


Subtask a 


Work to be Performed 

Prepare an Earth Sciences Data and Information System (ESDIS) Project 
Management Plan (PMP) consistent with applicable NMIs, local GSFC management 
and documentation guidelines and existing EOS program plans. This activity will 
include development of a project Work Breakdown Structure (WBS) and project 
documentation tree for inclusion in the PMP. 

Deliverables and Schedule 

First draft: 2/1/95 

Second draft: 2/15/95 

Final: 3/8/95 

Amendment #1 

Final: 8/9/95 

Per direction from the ATR, consider work on this subtask complete by this date if 
no comments on the latest PMP draft have been received by then from the ESDIS 
Project (Code 505) 

Accomplishments 

The 1st draft of the PMP was delivered on 2/13/95 and the 2nd draft was delivered 
on 2/28/95. Work on the final version was held up pending receipt of comments 
from the 6 ESDIS Project reviewers designated by the ESDIS Project Manager. 
Changes were made based on inputs from 3 of the 6 reviewers, but comments were 
not received from the other designated reviewers nor from the Project Manager. 
Delivery of the final version of the PMP by the required date was therefore not 
possible. 

At the direction of the ATR, a 3rd draft incorporating those comments that were 
provided was delivered to the ESDIS Project Manager on 5/16/95. Work on the 
PMP was then suspended awaiting responses. When no additional comments were 
received by August, the ATR agreed that no further work on this subtask should be 
planned by GST. Amendment #1 formally established a revised completion date for 
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this subtask as 8/9/95, and the 3rd draft PMP delivered on 5/16/95 became the final 
deliverable. 

Miscellaneous other activities related to the ESDIS PMP were performed at the 
ATR's request. These included: 

1) Reviewing and providing comments on revised NMI 7120.4 and NHB 7120.5 
"Management of Major System Programs and Projects" (these documents 
strongly influenced the structure and content of the ESDIS PMP), 

2) Researching and providing information on matrix management approaches 
applicable to Code 505 (one such approach was reflected in the PMP), and 

3) Attending meetings with people in or supporting the MO&DSD who desired 
to benefit from our work on the ESDIS PMP. 


Subtask b 


Work to be Performed 

Prepare an ESDIS Project Systems Engineering Management Plan (SEMP) consistent 
with the developed PMP. The SEMP will define the processes and responsibilities 
associated with conduct of ESDIS systems engineering functions, including those 
internal to the Project and those relating to external organizations. 

Deliverables and Schedule 

First Draft: 4/12/95 

Second Draft: 5/10/95 

Final 5/31/95 

Amendments 


None 

Accomplishments 

This work was scheduled to start in Mid-February. Although a query was received 
in January from the ESDIS Project concerning the possibility of accelerating the 
SEMP delivery schedule (this query was referred to the ATR), no direction was 
received from the ATR to do so. Consequently, work on the SEMP started as 
planned on 2/22/95. 

An annotated outline of the SEMP was prepared and delivered to the ESDIS Project 
in early March. At that time, the ESDIS Systems Manager requested that a Systems 
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Management Plan (SMP) be written rather than an SEMP. The SEMP was 
restructured, an annotated outline created, and work on the first draft SMP was 
delivered on 4/13/95. Annotated outlines for an SEMP and a Mission Management 
Plan (MMP) were also delivered at that time. 

No responses were received from the Project through the rest of April, and at the 
end of April this work was suspended. Delivery of a second draft on 5/10/95 was 
therefore not possible. It was agreed with the ATR and the ESDIS Project on 5/23/95 
that because of the limited opportunity to interact with Project personnel on these 
documents it would be more effective for the Project to complete these documents 
internally. As requested by the project, we then delivered (on 5/26/95) hardcopies 
and softcopies of the revised 1st draft ESDIS SMP, the annotated outline of the 
ESDIS System Engineering Management Plan and the annotated outline of the 
ESDIS Mission Management Plan. This completed the work on this subtask. 


Subtask c 


Work to be Performed 

Evaluate ESDIS and related EOS program requirements development, management 
and analysis processes. This assessment is intended to identify opportunities to 
improve the effectiveness of these processes and program /project responsiveness to 
requirements. Specific topics will include (1) an assessment of the user community 
processes for establishing science data processing requirements, ESDIS/user 
interactions thereon and internal ESDIS processes for interpretation of these 
requirements and conversion into system specifications, and (2) the EOS /ESDIS 
requirements allocation process. 

Deliverables and Schedule 

First Report (briefing): 4/5/95 

Second Report (briefing): 5/10/95 
Final Report (briefing): 6/14/95 

Report Update (briefing): 12/20/95 

Amendment #1 

Merge the findings and recommendations of Subtasks c and d into a briefing for Dr. 
Dale Harris and others. Coordinate this work with a Code 504 person designated by 
the ATR. This will be the final report for these subtasks 

Final Report (briefing): 7/27/95 

Delete Report Update 


3 



Accomplishments 


An initial analysis of the requirements management process was completed and 
presented to the ATR in January. An assessment of how MODIS science data 
processing requirements are developed was also completed. Uncertainties 
concerning these requirements, and assumptions being used to arrive at 
computational resource needs, were analyzed and discussed with various GSFC 
personnel. Results of these analyses were presented to the ATR on 2/28/95. Several 
discussions were held with ESDIS Project personnel to understand in greater depth 
how they handle science requirements and establish L1-L2 traceability. All of this 
information was analyzed and the First Report briefing was presented to the ATR 
on 4/3/95. 

Recommendations to improve requirements management were then developed. 
Meetings were held with the ATR to further discuss requirements management 
issues and strategies, and how to present the analyses and recommendations to the 
ESDIS Project. The synergistic relationship between the recommendations being 
developed under this subtask and those being developed under Subtask d (cost 
estimating and modeling) became evident, and the ATR concurred in our 
recommendation to combine the final phases of the work under these subtasks into 
a single briefing for the ESDIS Project. It was understood that this approach would 
be reflected in an amendment to Task #2. This agreement removed the 
requirement for the Second Report briefing on 5/10/95 and for the Report Update 
on 12/20/95, and changed the Final Report date to 7/27/95. 

Work on the integrated Subtask c/d briefing began in June with a target date of 
7/25/95 for presentation to the ESDIS Project. Several dry-runs to the ATR and 
Code 504 personnel were conducted between mid-June and mid-July. 

Recommended changes were made to the briefing between dry-runs. The briefing to 
the ESDIS Project (Code 505) scheduled for 7/25/95 was canceled (that day) due to 
work conflicts in Code 505, and was presented on 8/8/95. 

In discussions that followed the briefing, direction was given to prepare a more 
detailed plan and cost estimate for developing and demonstrating an integrated 
process and cost model for a suitable subset of EOSDIS requirements and capabilities. 
This work would be continued under Subtask f. Presentation of the 8/8/95 briefing 
therefore constituted completion of the work under Subtask c. 


Subtask d 


Work to be Performed 

Evaluate overall ESDIS cost estimation processes and construct recommendations 
for improvements and extensions thereto. This assessment will include system 
planning, development and operations for the life-cycle, and is intended to identify 
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approaches to maximize reliability of estimation in management decision-making. 
The recommendations from this evaluation should include prospective cost- 
modeling tools available within the Center or elsewhere and a proposed ESDIS 
implementation of an appropriate suite of capabilities. 

Deliverables and Schedule 

First Report (briefing): 4/12/95 

Second Report (briefing): 5/31/95 
Final Report (briefing): 6/28/95 

Report Update (briefing): 12/20/95 

Amendment #1 


Merge the findings and recommendations of Subtasks c and d into a briefing for Dr. 
Dale Harris and others. Coordinate this work with a Code 504 person designated by 
the ATR. This will be the final report for these subtasks. 

Final Report (briefing): 7/27/95 

Delete Report Update 

Accomplishments 

As planned, work began on this subtask in late March. Meetings were held with the 
ECS cost estimator (Chris Daly) to understand ECS cost estimating methodology and 
with the Resources Analysis Office (Code 152) on their methods, and literature was 
researched on cost estimating approaches. The First Report (briefing) was prepared 
and presented to the ATR on 4/17/95. 

Work then continued on the analysis of cost estimating and modeling techniques 
used by the Project. Analyses were also made of modeling techniques used by others 
that might improve current practices in the Project. Collection of information 
continued on NASA (e.g., JPL, Space Station, MO&DSD) and non-NASA (mostly 
DoD) cost estimation and modeling methods. Additional meetings were held with 
the Ecom and EDOS Projects to obtain an understanding of their respective cost 
estimating and modeling methods. Demonstration of a very effective technique 
was provided by the Ecom Project. The Second Report (briefing) was prepared and 
presented to the ATR on 6/1/95. 

Recommendations to improve cost estimating and modeling techniques were then 
developed. Meetings were held with the ATR to further discuss cost estimating and 
modeling issues and strategies, and how to present the analyses and 
recommendations to the ESDIS Project. The synergistic relationship between the 
recommendations being developed under this subtask and those being developed 
under Subtask c (requirements management) became evident, and the ATR 
concurred in our recommendation to combine the final phases of the work under 
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these subtasks into a single briefing for the ESDIS Project. It was understood that 
this approach would be reflected in an amendment to Task #2. This agreement 
removed the requirement for the Report Update on 12/20/95, and changed the Final 
Report date to 7/27/95. 


Work on the integrated Sub task c/d briefing began in June with a target date of 
7/25/95 for presentation to the ESDIS Project. Several dry-runs to the ATR and 
Code 504 personnel were conducted between mid-June and mid-July. 

Recommended changes were made to the briefing between dry-runs. The briefing to 
the ESDIS Project (Code 505) scheduled for 7/25/95 was canceled (that day) due to 
work conflicts in Code 505, and was presented on 8/8/95. 

In discussions that followed the briefing, direction was given to prepare a more 
detailed plan and cost estimate for developing and demonstrating an integrated 
process and cost model for a suitable subset of EOSDIS requirements and capabilities. 
This work would be continued under Subtask f. Presentation of the 8/8/95 briefing 
therefore constituted completion of the work under Subtask d. 


Subtask e 


Work to be Performed 

Evaluate present ESDIS schedules and scheduling tools and provide overall 
recommendations with respect to identified issues of schedule accomplishment. As 
indicated on the basis of conclusions, provide guidance for the development of 
resource-loaded critical path networks and develop approaches to maximize the 
utility of schedule networks in management decision-making. 

Deliverables and Schedule 

First Report (briefing): 4/12/95 

Second Report (briefing): 5/31/95 
Final Report (briefing): 6/28/95 

Report Update (briefing): 12/20/95 

Amendment #1 

Change this subtask to read "Define and justify project management schedule 
information needs. 

First Report (briefing): 7/12/95 

Delete Second Report 
Final Report (briefing): 8/9/95 

Delete Report Update 
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Accomplishments 


As planned, work began on this subtask in late March. Meetings were held with the 
ESDIS DPM/R (George Barth) and the ESDIS Scheduling Manager (Keith 
Opperhauser) to understand current ESDIS scheduling methodology and 
implementation. The extent to which such schedules were based on resource- 
loaded activities was analyzed. Alternative techniques for developing and 
managing resource-loaded critical path schedules were also briefly analyzed. 

It was determined relatively quickly (in early May) that: 

1) The current ESDIS scheduling system ("Prestige" software on a PC-based 
LAN) was being used nearly to the full extent of its software and hardware 
capabilities; 

2) Even though there are now better ways to implement the ESDIS 
scheduling function to improve ESDIS schedule management products, it 
would be a major impact to the Project to make the software and hardware 
changes that would be needed; 

3) The ESDIS scheduling data base had recently been established as a shared 
database with the EOS Project, and any change to the ESDIS system would 
have a significant impact in this area; and 

4) Progress was being made, albeit somewhat manually, to establish more 
effective relationships between the schedule and the resources required and 
available to accomplish that schedule. 

With the consent of the ATR, work on this subtask was suspended in mid-May. 

In June, it was agreed with the ATR to re-define this subtask according to the 
language planned for Amendment #1. It was also agreed that this work should be 
the lowest priority of all work on Task #2 and should not resume until 
Amendment #1 was approved and work on other subtasks had been mostly 
completed. However, no more work was done on this subtask because Amendment 
#1 was not received until 12/8/95 and the furlough beginning 12/16/95 did not 
permit adequate opportunity for Government direction before the close-out of Task 
#2 on 12/31/95. 
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Subtask f 


Work to be Performed 

Evaluate ESDIS Project, Directorate and EOS Program practices and activities in the 
following areas and make appropriate recommendations to the MO&DSD and the 
ESDIS Project. In these areas specific follow-up research, recommendations and/or 
reports may be required: 

(1) Risk assessment, risk mitigation strategies and approaches, and use of 
risk information in management decision-making 

(2) Prototyping, technology assessments and insertion 

(3) System integration and validation 

(4) System, science and operations concept development, including system 
evolvability 

Deliverables and Schedule 

Status briefing on the 1st Monday of each month starting 4/24/95. 

Final report (briefing) on 12/20/95. 

Other briefings and/or reports as required 

Amendment #1 


Add item (5) as follows: 

(5) Assess the feasibility of an improved MTPE system management process 
which would be supported by a computer-based model which encompasses 
top-level cost modeling and associated major cost drivers (e.g., critical 
requirements, costly functions and capabilities, price vs. performance 
relationships, and price vs. time relationships. Develop a prototype process 
model using a selected subset of MTPE cost-related drivers that are sufficient 
to demonstrate the feasibility (or lack of feasibility) of the approach. 

Item (5) is to be complete by 12/20/95. 

Accomplishments 

The original 4 areas of work under this subtask were predicated on the development 
of arrangements within GSFC by which the MO&DSD would actively support 
various EOSDIS systems engineering initiatives of the GSFC MTPE Office (Code 
170). Work was planned to start on this subtask in the March timeframe after these 
arrangements had been made. 
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No such arrangements were successfully established between these two 
organizations. Nevertheless, in April we were asked for and provided 6 System 
Team issues pages for Mr. Paul Caruso/Code 170 and later, also at Code 170's request, 
provided analysis of these issues and identified associated team responsibilities. 

In late June, discussions with the ATR resulted in new direction on this subtask that 
would be included in a pending task modification (Amendment #1). These 
discussions acknowledged that support to Code 170 according to the original subtask 
language would not occur. The significant reduction in overall Task #2 effort 
resulting from this change prompted a complete re-plan of Task #2 and the 
generation of a significantly revised CTR (a reduction of approximately $123K 
through 12/31/95 Task #2 completion). 

In accordance with these changes, work was initiated on assessing the feasibility of 
an improved MTPE system management process that would be supported by a 
computer-based model encompassing top-level cost modeling and associated major 
cost drivers. This was directed toward the objective of developing a prototype 
process model using a selected subset of MTPE cost-related drivers that would be 
sufficient to demonstrate the feasibility of the approach. Such a model would have 
system engineering applications both in the ESDIS Project and in the GSFC MTPE 
Office. 

Additional direction in this area was received at the 8/8/95 briefing of Subtask c and 
d results to the ESDIS Project. Further, the ATR delegated technical management 
responsibilities for this work to the MO&DSD Systems Engineering Office (Code 504) 
and directed that henceforth we should work with and through them on this 
subtask. 

Based on this direction and discussions with Code 504, we initially: 

1) Drafted and delivered a more detailed SOW for GST tasks associated with 
modifying and applying the Veda International CASEMM process/ cost 
modeling tool. 

2) Developed and delivered plans, schedules, and resource estimates to 
manage and accomplish this work. 

3) Initiated the approval cycle for procurement of a computer system to host 
the CASEMM tool, including preparing and submitting a request for approval 
to the CO. 

4) Met with Veda, Inc. and developed an approach for working this task 
together, including an integrated SOW (GST Organizational Conflict of 
Interest [OCI] issues were recognized). 
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5) Jointly (GST and Veda) met with Code 504 on 8/24/95 and presented the 
draft SOWs and the results of the joint planning activities (schedules, 
estimated costs, proposed products). 

6) Demonstrated the current version of the CASEMM tool to Code 504 
personnel, together with discussions of how the tool would be extended and 
enhanced for use by the ESDIS project. 

Code 504 advised on 8/31/95 that we should initiate the GST portion of this joint 
work within the scope of this subtask (as amended), and that acquisition of Veda s 
services to modify the CASEMM tool would proceed. It was understood that 
additional funding from the ESDIS Project would be needed for continuation of 
GST's work beyond 12/31/95 (probably via the impending MO&DSD/GST task order 
contract) as well as to fund Veda for CASEMM modifications (probably via an 
existing Veda subcontract under the NMOS contract). 

In September and early October, GST: 

1) Finalized and delivered plans including, tasks, critical path schedules, 
labor resource estimates, and costs. 

2) Met several times with Veda to discuss plans and resource estimates. 

3) Conducted another demonstration of CASEMM for Code 504. 

4) Analyzed alternative approaches when the GST computer purchase was 
denied by the CO due to a contract clause prohibiting a contractor from 
purchasing "facilities" with government funds. 

5) Initiated research and data collection for information needed in further 
developing the CASEMM tool and applying it to the ESDIS Project needs. 

6) Conducted weekly coordination meetings with Code 504. 

7) Prepared and presented a briefing on the CASEMM tool development 
plans to the ESDIS Project, and participated in a demonstration of the tool to 
the ESDIS Project. 

However, because of NASA furloughs, uncertainty about the FY96 MTPE budget, 
involvement of ESDIS Project managers with responses to external reviews, and 
growing potential for significant re-direction of the EOSDIS program, focused 
direction (and FY '96 funding) for this modeling work by GST and Veda never 
occurred. By late October, because of this lack of direction and with the concurrence 
of the ATR, GST scaled back its work and focused primarily on collecting data and 
researching various tools and methods that could be used to support the modeling 
effort. 
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Meetings with ESDIS managers to follow-up the CASEMM demonstration could not 
be arranged. However, on 11/13/95 (via e-mail) the ESDIS Deputy Project Manager 
(DPM) advised "We are inclined to initiate a short term effort with you to use 
CASEMM to model the federation alternatives at some level". With this 
"encouragement", we continued collection of data and other research for use in the 
CASEMM tool development for ESDIS Project or Code 504 applications. We also 
reviewed descriptions of a system engineering tool called SLATE, attended a 
demonstration of the tool, and discussed SLATE applications and operations with 
the tool vendor. We understand that SLATE may be used by the ESDIS Project to 
complement the capabilities of CASEMM. 

On 12/11/95 the ESDIS DPM indicated the possibility of a meeting after 12/20/95 to 
discuss this further. However, by 12/15/95 the ATR had decided not to extend this 
task and by 12/16/95 NASA was again on furlough. On 12/20/95, GST stopped all 
work on this subtask and initiated preparation of the Task #2 Final Report. A 
summary of the research work done on process /cost modeling is contained in 
Attachment B to the Final Report. 


Subtask g 

Work to be Performed (per Task Amendment #2) 

Research the technical and system engineering aspects of the Business Process 
Reengineering (BPR) methodology as it would apply to the MO&DSD and its 
mission support data systems. Advise on how technical and systems engineering 
matters (such as data system architecture and data service/data product quality 
considerations) could be dealt with in an MO&DSD BPR exercise. 

(This is the draft of Amendment #2 as discussed with the ATR on 11/9/95. 
Because of the NASA furlough in effect since December 16, 1995, GST has not 
formally received Amendment #2. As discussed with and directed by the 
Contracting Officer in November, this amendment was intended to provide 
wording for the draft Subtask g previously provided by the ATR. Since the 
probable wording of this amendment had been discussed among GST, the 
ATR and the CO, and since the work according to the expected wording of 
Subtask g has been completed, this report includes Amendment #2. 

Deliverables and Schedule 

Include findings in ATR's weekly meeting starting 7/12/95 
Complete all work by 9/8/95. 
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Accomplishments 


All the work performed by GST related to Subtask g was accomplished from June 
through August 1995. 

All work accomplished was in preparation for performing system engineering work 
under Subtask g and was primarily to develop a better understanding of MO&DSD 
data system engineering issues associated with Business Process Reengineering 
(BPR). BPR is a structured methodology for "re-inventing" the business and 
technical processes, services and products of an organization. This first phase of the 
task was primarily for the purpose of clarifying everyone's understanding of BPR 
methodology from a technical perspective (e.g., how is MO&DSD data system 
architecture and performance affected) and would also serve to develop a more 
definitive agreement with the ATR on the deliverables required of GST under this 
subtask. We believe this work was within the scope of the contract and of the task 
because it was in preparation for performing systems engineering work regarding 
future MO&DSD data systems. The purpose of such work would have been to 
technically define data system architectures and designs. 

Because of the possibility of a future MO&DSD solicitation in this area and the 
possibility that GST would want to participate in responding to such a solicitation, 
the potential for Organizational Conflict of Interest on this subtask was envisioned 
from the outset. The ATR and GST took what are believed to be appropriate 
precautions. For example, it was understood that GST would not have or be 
required to have access to proprietary or source selection information that might be 
applicable to a solicitation for BPR services. Also, GST would not be asked to 
provide task specifications or statements of work that would be incorporated into 
such a solicitation. 

GST's understandings of the technical aspects of the BPR process were orally 
imparted to the ATR through late July. At this time it became evident that the 
business, management and technical aspects of this process were so interrelated that 
it was unlikely that technical work could successfully be performed separately under 
this subtask. From that point on, GST efforts on this subtask were phased out. 
MO&DSD then began exploration of full BPR support from other contractors 
currently available to NASA. As of the writing of this Final Report, however, GST 
is not aware of any decisions by the MO&DSD to acquire such support. 

The work that GST performed under this subtask was as follows: 

1) Developed planning information for the revision of the Task 2 CTR on 

this contract to reflect the addition of Subtask g. 

2) Became familiar with the technique of Business Process Reengineering 

(BPR) and identified how technical and systems engineering matters (such as 

data system architecture and service quality impacts) are dealt with in BPR. 
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This included discussions with a company that is expert in BPR and is 
currently working for NASA (KPMG Peat Marwick) and an organization at 
GSFC (NSSDC) also attempting to deal with BPR/ technical interactions. 

3) Met with the ATR several times -- usually as part of overall task 
coordination meetings with the ATR and sometimes with other MO&DSD 
managers present -- to discuss and orally impart our understandings of the 
technical component of the BPR process. GST described our understanding of 
how systems engineering and other technical issues which that impact 
MO&DSD data systems (including MTPE) might be dealt with during a BPR 
exercise. Such work would have included performing analyses and 
engineering in areas such as space data information management and 
distribution, data storage system architecture, advanced information system 
architecture, high speed digital communications, data system interfaces, data 
system operations, and distributed resource management and control. The 
purpose of such work would have been to technically define data system 
architectures and designs consistent with the business and management 
alternatives being considered by others in the BPR process. 
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ATTACHMENT B 


Summary of Work Performed Under Subtask f , Item (5) 


This report provides information in three areas: 

1) Research, including university, government, and private, 

2) Internet web site locations that led us to some promising areas of 
development, and 

3) Software tools and models that are currently available or are under 
development. 

This is a limited selection of data from a vast amount of data that exists. Had more 
resources been available to continue this task, more data could have been presented 
It is hoped, however, that what is being provided will be of value to future work in 
the arena of cost estimation and modeling. 


Research 

University Research on Cost Estimation 

University of Iowa - College of Business Administration 

How are Costs Estimated ? Lecture notes for Introduction to Management 
Accounting. Good theoretical description of cost estimation elements and 
processes. 

Genopersistation (Dean-1993) 

A recursive concept to facilitate the analysis and synthesis of systems. To 
genopersist an object means to bring forth, sustain, and retire that object. It is 
an action upon an object and has both mathematical and systemic meaning. It 
is the functional equivalent of the life-cycle. 

Hierarchical Storage Management for Relational Databases 

A concept that has the potential to optimize the cost and performance of data 
storage and access by automatically managing the placement of data on 
different storage media. Paper describes a prototype that integrates a DBMS 
with a storage management system, allowing simple, cost effective access to 
large volumes of data stored in a tape archive. 


Government Research 
Langley Research Center (Dean) 

Design FOR Cost - Designing FOR cost is the conscious use of engineering 
process technology to reduce life-cycle cost. Design TO cost is the iterative 
redesign of a project until the content of the project meets a given budget. 
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Designing for cost seeks to increase system performance while reducing cost. 
Design to cost usually reduces performance until the budget is met. Designing 
for cost is an engineering driven process. Design to cost is a management 
driven process. Designing for cost seeks to design the product only once and to 
minimize the life-cycle cost by designing in high quality. Design to cost is 
iterative by nature and incurs redesign and rework cost. 

Parametric Cost Analysis - Parametric estimating relies on simulation models 
that are systems of statistically and logically supported mathematical 
equations. The impacts of a product's physical, performance, and 
programmatic characteristics on cost and schedule are defined by these 
equations. Parametric cost analysis is the set of processes by which appropriate 
characteristics of systems are mapped to appropriate ranges of cost. Given 
these mappings, one can then estimate cost, estimate the variability of cost, or 
design for cost with respect to the given system characteristics. Parametric cost 
analysis provides an excellent tool for estimating cost and cost uncertainty 
(using probabilistic methods to simulate), and can be used to design for cost 
with Taguchi methods, response surface methodology, or multidisciplinary 
optimization. Optimizing for cost illuminates a previously undiscovered 
form of cost driver. This research indicates that more appropriate drivers 
come from the system to bring forth, sustain, and retire the system to be 
estimated (genopersistation). 

Parametric Cost Deployment - Parametric cost analysis is a mathematical 
approach to estimating cost. Parametric cost analysis uses non-cost parameters 
to estimate the cost to bring forth, sustain, and retire a product. Basic concept 
is to match value with cost. Cost deployment is a means of designing for cost. 

Concurrent Engineering - Also known as simultaneous engineering is 
designing for all of the attributes of a product. It's use tends to reduce cycle 
time and to reduce cost when appropriately applied. 

Goddard Space Flight Center 

TMAACS Project - Integrated Monitoring, Analysis, and Control System 
attempts to combine COTS software and hardware with existing legacy tools. 
Successful demonstration shows that these products can be combined and 
work together with real mission data. 

COGS - Part of Code 501 Planning, Analysis, and Coordinating Environment 
(PACE) Process which includes Renaissance capabilities, ASSET, & NCASEMM 

Johnson Space Center - Parametric Cost Estimating Reference manual 
Cost Estimating Guidelines 
Cost Estimating Associations (listing) 

NASA Cost Model (NASCOM) 

Jet Propulsion Laboratory 

Mission Operations Staffing Spreadsheet (J. Caraway) 
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DoD - Dept, of Army 

Cost Analysis Manual 
Economics Analysis Manual 
National Media Lab 

Life Cycle Costs - (L. Ptasienski from LaRC) Excellent work on life-cycle costs 
but limited to advanced electronic storage systems. 


Commercial Development 

Cost Management Model (CMM ) - ECON, Inc. Developed in 1988 using Fortran 77, 
this large, expensive, and constraining model seems to be outdated by more current 
developments. 


Internet Addresses 

Below are listed a sampling of some of the more interesting WWW sites that we 
explored during the performance of this task. There are many more sites that could 
have been listed and some of the more obvious sites, such as GSFC, JPL, JSC, etc., 
were not included. No ranking or special value is intended in this listing. 

Name URL 

INCOSE http : / / us w. interact. net:80/ N COSE / 

The International Society of Parametric Analysts http://mijuno.larc.nasa.gov/dfc/societies/Ispa.html 
Cost Technology Home Page http://mijuno.larc.nasa.gov/dfc/ctec.html 

TD Technologies (SLATE) http://www.slate.tdtech.com/ 

Advanced Simulation and S/W Eng Tech http:/ / pike.cecer.army.mil/ 

Mid-Atlantic Technology Applications Center http://oracle.mtac.pitt.edu/WWW/MTAC.html 
The National Technology Transfer Center (NTTC) http://iridium.nttc.edu/nttc.html 
Center for Networked Info Discovery & Retrieval http:/ / www.cnidr.org/welcome.html 
National Media Lab http://www.nml. 0 rg/#t 0 p 

Data Storage Systems Center 

http:/ / www. ece.cmu.edu/afs/ece/www/httpd_doc/ research/ dssc.html 
Institute for Systems Research (ISR) http://www.isr.umd.edu/ 

Applied Economics Lab, Portland State Univ http://eclab.ch.pdx.edu/ 

Center for Discrete Mathematics and Theoretical Computer Science 

http: / / dimacs.rutgers.edu/ 
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Tools Available 


Below is a sampling of some of better software tools that are available or under 
development at the current time. Included along with this listing is a short 
description and evaluation of each tool. 

ACASEMM fAir Force) / NCASEMM (NASA - front end only) - Veda, Inc. 

CASEMM (Computer-Aided Systems Engineering and Management Model) is 
a PC-based analysis tool that provides an integrated environment to model 
cost and operational effectiveness of complex process-like tasks. CASEMM is 
an open architecture, object-oriented, knowledge-based fully integrated model 
that is specifically tailored for rapid process definition, simulation, costing, and 
evaluation. With this tool, the dynamic relationship between system 
requirements, performance, and costs can rapidly be assessed and contains a 
unique capability for data analysis. 

ANATOOL 

Uses Structured Systems Analysis (SSA) for modeling information systems to 
provide a method for project managers and systems analysts to accurately and 
clearly describe complex data flows. Tool assists and yet requires conformity to 
SSA requirements while automating many of the tedious processes necessary 
for creating SSA documents. 

ASSET (Advanced Simulation & Software Engineering Technology) U.S. Army 
Research incomplete; not much data found. 

ClearCase fS/W) 

Research incomplete; not much data found. 

COGS (Cost Analysis Module of ASSET) 

Under development by GSFC, Code 501. 

Data System Performance Modeling 

Code 520 models designed to ensure that optimal data systems are developed 
which have known behavioral characteristics and which predict the 
performance of emerging Code 500 data systems. They are used to study the 
effect, and mitigate the risk of system engineering decisions. Different 
approaches are utilized together with the models to simulate data system 
performance. 

DEFT 

CASE system for designing relational databases. Large, very complicated to 
learn and use, and expensive. 

Digraph 

Used on NASA's Space Station Project (and others) for failure analysis. 
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DSDS+ (Data System Dynamic Simulator) 

Discrete-event based simulator to simulate complex, high-data-rate, end-to- 
end data systems. Models data traffic of a system to determine size of data 
links, speeds of components, sizes of buggers in the components, etc. Features 
hierarchical modeling plus a graphical interface that utilizes elements such as 
data generators, CPUs, switches, orbit calculators, and schedulers, linked 
together to form the model. 

RDD-100 

Used extensively by the government and NASA for generating and tracking 
requirements. 

RGS (Requirements Generation System) 

Utilizes and interactive processing environment to automate many of the 
activities associated with the development, editing, review, and approval of 
requirements, and the creation of requirements documents. RGS data base 
facilitates communication of information about all levels of mission 
requirements and whose hierarchical structure ensures requirements 
traceability. 

SA/BPR : System Architect/Business Process Reengineering 

An affordable, PC-based, powerful, and user friendly tool for creating business 
models using the IDEF methods (IDEFO /Function Modeling and 
IDEF3/Process Modeling and Object State Modeling). 

Satellite Tool Kit (Analytical Graphics) 

Powerful, interactive, graphical analysis software tools to provide engineers 
the ability to access, manage, display and manipulate satellite data for mission 
planning, modeling and analysis. New version released for the high-end PC 
world. 

SLATE (System Level Automation Tool for Engineers) 

A dynamic, multi-user, integrated information system for organizing and 
managing the product life cycle. It is a client-server system using an object- 
oriented database and can be used to capture original requirements, manage 
and analyze the design, and implement a design model for the entire product 
life cycle. 

SYNERGE (Systems Engineering Environment) 

Code 522 prototype of a multi-user tool for designing, creating, browsing, 
editing and analyzing complex sets of system engineering information. 
Simple, low-cost, desktop-based single point of access to project requirements, 
interface definitions, schedules, and other information using information 
system technology to also facilitate training, assure information consistency 
and completeness within and between projects. Operational prototype 
completed in 1993. 

TOPIC - Research incomplete; not much data found. 
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While some of the above tools are excellent for their specific application, none of 
them have the capability of generating top-level cost estimations using parametric 
cost estimation relationships (CERs) with the exception of Veda's ACASEMM. 
However, it is specifically designed for use with the Air Force's systems, processes, 
and CERs and would have to be integrated with the NASA version of CASEMM 
and modified to include the back-end (ground systems) and NASA appropriate 
CERs. 
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